To write (also referred as “print”) to a disc in a CD drive, an interface is needed to allow an imaging application to send data to the drive. In a personal computer (“PC”) with a Windows operating system (“OS”), access to the CD drive is usually done through the cdrom.sys class driver. Interfacing with the class driver requires very low level programming and is not an easy way for an imaging application to send to send print data.
As shown in FIGS. 1A and 1B, a standard computer system 100 includes a CD-ROM drive 108 which is modified to support printing and is programmed to recognize specific small computer system interface/attachment packet interface (“SCSI/ATAPI”) commands that are only used for printing. In this system 100, a Windows application 102 (shown as “102A” and “102B”) interfaces with an OS class driver 104 using input/output control (“IOCTL”) language. However, because these commands are non-standard, it is necessary to bypass error checking protocols. Accordingly, the traditional approach is to use an SCSI-pass-through-interface (“SPTI”) 106 interfaced with the OS driver 104.
As shown in FIG. 1A, if the Windows application 102 is an application with administrator privileges 102A (i.e., the user has administrator privileges and this status is recognized by the system 100), when using an SPTI 106, the class driver 104 passes the raw print command data to the CD drive 108 via a port driver 130, an intelligent drive electronics (also known as “integrated drive electronics” or “IDE”) bus driver 140, and an IDE bus 110; the SPTI does not interfere with or check the data. The driver 104 confirms the administrator privileges status before sending signals to the SPTI. For those applications with administrator privileges 102A, the SPTI will send SCSI/ATAPI print commands to the CD drive 108. By way of contrast, as shown in FIG. 1B, if the application does not have administrator privileges 102B (i.e., the user does not have administrator privileges and this status is recognized by the system 100), this status information is also passed to the driver 104; as a result, the driver 104 will not send print signals to the SPTI which, in turn, prevents the signals from reaching the CD drive 108.
As a result, to use an SPTI, an application must have administrator privileges (i.e., the user must have administrator privileges). However, as most PC users, particularly those on a network, do not have administrator privileges, the SPTI is usually unavailable, thereby preventing print commands from reaching the CD drive 108.
There are two predominant prior solutions to this administrator access problem. First, as shown in FIG. 2, another system 150 has been developed using an IDE bus 110 but not using standard SCSI commands or drivers. This system 150 uses a second, customized driver 112 to control the data and control lines of the IDE bus 110 to send print data to the CD drive 108.
Unfortunately, as a result of using specialized commands to overcome the print access problem associated with no administrator privileges, this system 150 does not support standard drivers such as the class driver 104 that is already a part of the OS. As a result, the second driver 112 is necessary to act as an interface between the application without administrator privileges 102B and the IDE bus 110 via the port driver 130 and IDE bus driver 140. The second driver 112 may receive the same print commands as the OS driver 104 or may receive specialized print commands as a result of being interfaced with the custom driver. However, the second driver 112 is customized to convert the driver commands of the application 102B into non-SCSI commands which are sent through the bus 110 to the CD drive 108.
The second solution, shown in FIG. 3, involves a system 175 which, like the standard OS shown in FIG. 1A, uses SCSI commands to control the CD drive 108. However, in this system 175, the SCSI commands reach the CD drive 108 via a third party CD driver 114 that is not part of the OS. An example of such a driver is the Advanced SCSI Programming Interface (“ASPI”). Unfortunately, third party drivers require license fees and have limited technical support in current operating systems. It should be recognized that in this system, the application without administrator privileges 102B interfaces with the system driver 104, the SPTI 106, and the third party driver 114. The OS driver 104 and the third party driver 114 receive the same print commands and unlike the previously described systems (in which administrator status signals were communicated to the system driver 104), in this system 175, the status signals are communicated to the SPTI 106. However, like the previously described system 150, the SPTI 106 is bypassed; in this system 175, the bypass is via the third party driver 114.